20장 테스트 코드 쓰기 (입문판)

원서: 클로드 코드 완벽 가이드, 코드팩토리 최지호

이 장에서 딱 4가지만 기억하세요. 1. 테스트는 "내 코드가 잘 도는지 자동으로 확인하는 코드"다. 2. 클로드 코드한테 테스트 시킬 땐 "바로 짜지 말고 먼저 계획부터" 시킨다. 3. 작은 단위를 따로따로 보는 게 유닛 테스트, 처음부터 끝까지 사용자처럼 보는 게 E2E 테스트다. 4. 여러 일꾼(서브에이전트)을 동시에 굴리거나, Playwright MCP를 붙이면 테스트 짜기가 훨씬 빨라진다.

이 장에서 배우는 것 (학습목표)

• 자동화된 테스트가 왜 필요한지 설명한다.
• 유닛 테스트, 통합 테스트, E2E 테스트를 구분한다.
• 클로드 코드에게 테스트 계획부터 시키는 4단계 흐름을 따라 한다.
• 서브에이전트를 병렬로 굴려 유닛 테스트를 짜는 방법을 설명한다.
• Playwright MCP와 커스텀 커맨드로 E2E 테스트를 자동 생성하는 흐름을 따라 한다.

1. 테스트는 왜 짜야 할까?

이런 적 있죠? 기능 하나 고쳤는데 엉뚱한 데가 또 망가진다. 그래서 매번 손으로 다시 눌러보며 확인한다. 버튼 누르고, 새로고침하고, 또 누르고... 점점 지친다.

그게 바로 "수동 테스트"의 한계입니다. 손으로 일일이 확인하면 시간도 오래 걸리고, 사람이라 빼먹기도 합니다. 기능이 많아지면 전부 확인하는 게 아예 불가능해집니다.

여기서 등장하는 게 테스트 코드입니다. 테스트 코드란 "내가 만든 코드가 제대로 도는지 자동으로 확인해 주는 또 다른 코드"입니다. 한 번 짜두면 명령어 한 줄로 수백 개를 0.5초 만에 검사합니다.

일상 비유로 먼저

아플 때만 병원 가는 사람과, 정기 건강 검진 받는 사람을 떠올려 보세요. 수동 테스트는 "아프면 그때 가서 본다"입니다. 자동 테스트는 "정기 건강 검진"입니다. 정해진 검사를 빠르게 반복해서, 문제를 미리 잡아냅니다.

클로드 코드한테 특히 중요한 이유

클로드 코드는 코드를 고치면서 "이 변경이 기존 코드랑 합쳐졌을 때 괜찮나?"를 살핍니다. 이때 테스트 코드가 있으면 클로드 코드가 그걸 자동으로 돌려서 품질을 스스로 검증합니다. 즉, 테스트가 있으면 클로드 코드가 더 똑똑하고 안전하게 일합니다.

예시로 비교

손으로 하던 방식(매번 반복): 브라우저 열기 로그인하기 좋아요 버튼 누르기 새로고침하고 좋아요 그대로인지 확인 싫어요로 바꿔보기 또 새로고침... 기능 하나 바꿀 때마다 이걸 다 반복합니다.

자동 테스트(한 번 짜면 끝):

npx jest
# 35개 테스트 모두 통과 (0.5초)

코드를 바꿀 때마다 이 한 줄이면 전부 다시 확인됩니다.

잘못된 예 vs 올바른 예

잘못된 생각: "내가 직접 돌려보면 되지, 테스트 코드는 귀찮아." → 기능이 5개일 땐 괜찮습니다. 50개가 되면 손으로는 못 합니다.

올바른 생각: "자주 확인할 거니까 자동으로 검사하게 만들어 두자." → 처음 한 번만 수고하면, 이후로는 명령어 한 줄로 끝납니다.

이럴 때 이렇게: 좋아요/싫어요 같은 핵심 기능을 자주 손볼 것 같다면, 그 기능부터 테스트를 짜두세요.

여기서 한 번 점검

• 수동 테스트가 왜 느리고 위험한지 말할 수 있나요?
• 자동 테스트의 장점(반복·속도·일관성)을 설명할 수 있나요?
• 클로드 코드가 테스트를 어떻게 활용하는지 이해했나요?

2. 테스트 코드 "계획부터" 시키기

이런 적 있죠? 클로드 코드한테 "테스트 코드 짜줘" 한마디 던졌더니, 구조 없이 파일이 우르르 쏟아진다. 어디에 뭐가 있는지 헷갈리고, 나중에 정리하느라 더 고생한다.

그게 바로 "계획 없이 바로 코딩"의 함정입니다. 요리하기 전에 레시피부터 짜듯, 테스트도 구조와 계획을 먼저 세워야 합니다.

용어 한 줄: 유닛 테스트(unit test) 란 "함수나 작은 부품 하나가 제대로 도는지 따로 확인하는 테스트"입니다. 일상 비유로는 자동차에서 타이어 하나만 따로 점검하는 것과 같습니다.

일상 비유로 먼저

여행 가기 전에 짐 싸는 걸 떠올려 보세요. 무작정 가방에 던져 넣으면 막상 도착해서 뭐가 어디 있는지 모릅니다. "세면도구는 이 칸, 옷은 저 칸" 하고 먼저 칸을 정해두면 찾기 쉽습니다. 테스트도 폴더 구조라는 "칸"을 먼저 정해두는 게 핵심입니다.

단계 01 — 테스트 구조부터 구상

클로드 코드에게 "프로젝트를 보고 테스트 폴더 구조를 구상해줘. 단, 아직 테스트 코드는 작성하지 말아줘" 라고 요청합니다. 이 "작성하지 말아줘" 한마디가 핵심입니다. 이게 없으면 클로드 코드가 곧장 코드를 쏟아내서 구조를 검토할 틈이 없어집니다.

프롬프트 예시:

현재 프로젝트 구조를 파악하고 유닛 테스트 코드를 작성할 구조를 구상해줘.
아직 테스트 코드를 작성하지는 말아줘.

그러면 클로드 코드가 이런 폴더 구조를 제안합니다.

__tests__/
├── lib/                  # 핵심 비즈니스 로직 테스트
│   ├── preferences.test.ts
│   ├── cities.test.ts
│   └── utils.test.ts
├── components/           # 화면 컴포넌트 테스트
│   ├── cities/CityCard.test.tsx
│   └── home/HeroSection.test.tsx
├── hooks/                # React 훅 테스트
│   └── useLocalStorageMigration.test.ts
└── __mocks__/            # 가짜 객체(모킹) 모음
    ├── supabase.ts
    ├── next-router.ts
    └── localStorage.ts

용어 한 줄: 모킹(mock) 이란 "진짜 데이터베이스나 외부 서버 대신 쓰는 가짜 부품"입니다. 일상 비유로는 운전 연습장에서 진짜 차 대신 모형 차로 연습하는 것과 같습니다.

단계 02 — 무엇을 테스트할지 목록 만들기

폴더 구조가 마음에 들면, 이번엔 "어떤 파일의 어떤 기능을 어떤 상황으로 테스트할지 전부 정리해줘. 아직 코드는 작성하지 말고" 라고 요청합니다.

프롬프트 예시:

작성해야 할 유닛 테스트를 전부 정리해줘. 아직 테스트 코드를 작성하지는 말아줘.

그러면 클로드 코드가 우선순위별로 목록을 정리해 줍니다.

HIGH PRIORITY - 핵심 비즈니스 로직
1. preferences.ts - 사용자 선호도 관리
   - 좋아요 추가 (null → like)
   - 좋아요 취소 (like → null)
   - 좋아요에서 싫어요로 변경 (like → dislike)
   - 외부 저장소 에러 시 localStorage로 대체

용어 한 줄: fallback(폴백) 이란 "원래 쓰던 게 고장 났을 때 대신 쓰는 예비 방법"입니다. 일상 비유로는 정전됐을 때 켜는 손전등과 같습니다. 여기선 데이터베이스가 안 되면 브라우저 저장소(localStorage)로 대신 저장하는 것을 말합니다.

4단계 대화 흐름 (전체 그림)

테스트를 시킬 때 이 4단계 순서로 대화하면 깔끔합니다.

1단계: "구조를 구상해줘. 아직 작성하지 마."        → 폴더 구조 확인
2단계: "테스트 목록을 정리해줘. 아직 작성하지 마."   → 우선순위 목록 확인
3단계: "서브에이전트로 병렬 진행할 계획을 보여줘."    → 일 나누기 계획 확인
4단계: "계획대로 테스트 코드를 작성해줘."           → 실제 작성 시작

잘못된 예 vs 올바른 예

잘못된 요청: "테스트 코드 다 짜줘." → 구조도 우선순위도 없이 파일이 쏟아져 정리가 안 됩니다.

올바른 요청: "먼저 구조만 구상해줘. 아직 코드는 짜지 마." → 구조를 보고 마음에 들면, 그때 목록 → 코드 순으로 진행합니다.

이럴 때 이렇게: 처음 테스트를 도입하는 프로젝트라면, 반드시 1단계(구조)부터 천천히 밟으세요.

여기서 한 번 점검

• "구조 → 목록 → 코드" 순서를 이해했나요?
• "아직 작성하지 마"를 넣는 이유를 설명할 수 있나요?
• HIGH/MEDIUM/LOW로 우선순위를 나눌 수 있나요?

3. 유닛 테스트를 서브에이전트로 빠르게 짜기

이런 적 있죠? 테스트 짤 게 산더미인데, 하나씩 순서대로 짜다 보니 반나절이 훌쩍 간다.

그게 바로 "혼자 다 하기"의 한계입니다. 서로 상관없는 일이라면, 여러 명이 동시에 나눠 하면 훨씬 빠릅니다. 클로드 코드에는 이런 "여러 일꾼"이 있는데, 이걸 서브에이전트라고 부릅니다.

용어 한 줄: 서브에이전트(sub-agent) 란 "특정 일을 맡아서 따로 처리하는 작은 AI 도우미"입니다. 일상 비유로는 큰 행사를 준비할 때 음식·음악·장식을 각자 맡는 담당자들과 같습니다. (서브에이전트의 자세한 개념은 앞 장에서 다뤘습니다.)

일상 비유로 먼저

시험지 100장을 채점한다고 해 봅시다. 선생님 1명이 모든 과목을 다 채점하면 하루 종일 걸립니다. 선생님 4명이 각자 한 과목씩 맡으면 몇 시간이면 끝납니다. 서브에이전트 병렬 실행이 바로 이 "4명이 나눠 채점"입니다.

일 나누기 계획 예시

클로드 코드는 보통 이렇게 역할을 나눕니다.

Agent 1 (핵심 로직)   : preferences·cities 테스트   → 약 45개, 4~5시간
Agent 2 (화면 컴포넌트): CityCard·HeroSection 테스트  → 약 28개, 3~4시간
Agent 3 (훅·인증)     : useLocalStorageMigration 등  → 약 18개, 2~3시간
Agent 4 (인프라·모킹) : __mocks__, jest 설정 파일     → 1~2시간

인프라 담당(Agent 4)을 왜 먼저 끝낼까?

채점하려면 기준표가 먼저 있어야 하듯, 테스트를 돌리려면 모킹과 설정 파일이 먼저 있어야 합니다. Agent 4가 만드는 __mocks__/와 jest.config.js에 다른 에이전트들의 테스트가 기대고 있기 때문입니다. 그래서 Agent 4(인프라)를 먼저 → Agent 1~3을 병렬로 라는 순서를 지킵니다.

병렬로 했을 때 성과

순차 개발: 9~13시간
병렬 개발: 3~4시간
시간 절약: 5~9시간 (약 65~70% 단축)

(여기 나온 테스트 개수·시간 수치는 원서/노트 기준 예시이며, 실제 프로젝트마다 달라집니다.)

실제 테스트 코드는 어떻게 생겼나

Jest로 짠 유닛 테스트는 이렇게 생겼습니다. describe로 묶고, test로 한 가지 상황을 확인하고, expect로 결과가 맞는지 봅니다.

describe('toggleCityPreference', () => {
  test('좋아요 추가 (null → like)', () => {
    const result = toggleCityPreference(null, 'like');
    expect(result).toBe('like');
  });

  test('좋아요 취소 (like → null)', () => {
    const result = toggleCityPreference('like', 'like');
    expect(result).toBeNull();
  });
});

용어 한 줄: Jest 는 "자바스크립트 코드의 유닛 테스트를 돕는 도구"입니다. 일상 비유로는 답안지와 정답표를 자동으로 맞춰보는 채점기와 같습니다.

테스트 실행 결과 예시

npx jest
# 95개 테스트 모두 통과 - 4개 테스트 묶음 실행 완료
#  - 유틸리티 함수: 31개
#  - 폴백 데이터 관리: 26개
#  - 사용자 선호도: 35개  (좋아요/싫어요, DB/localStorage 폴백)
#  - 도시 필터링: 31개

잘못된 예 vs 올바른 예

잘못된 순서: 모킹·설정도 없이 Agent 1~3을 먼저 돌린다. → 테스트가 기댈 인프라가 없어서 실행조차 안 됩니다.

올바른 순서: Agent 4(인프라·모킹)를 먼저 끝낸 뒤, Agent 1~3을 동시에 돌린다. → 충돌 없이 빠르게 끝납니다.

이럴 때 이렇게: 서로 다른 폴더를 맡기면 충돌이 거의 없습니다. 같은 파일을 두 에이전트가 동시에 고치지 않도록 일을 쪼개세요.

여기서 한 번 점검

• 유닛 테스트가 "작은 단위를 따로따로" 본다는 걸 이해했나요?
• 병렬 실행의 장점(시간 절약)과 주의점(충돌)을 말할 수 있나요?
• 모킹이 왜 필요한지 설명할 수 있나요?
• 인프라 담당을 먼저 끝내는 이유를 아나요?

4. E2E 테스트란 무엇인가

이런 적 있죠? 부품 하나하나는 다 멀쩡한데, 막상 합쳐서 써보니 엉뚱하게 동작한다.

그게 바로 "부품 따로 검사"만의 한계입니다. 유닛 테스트는 부품을 따로 봅니다. 하지만 사용자는 부품을 따로 쓰지 않고, 처음부터 끝까지 이어서 씁니다. 그 "처음부터 끝까지 전체 흐름"을 확인하는 게 E2E 테스트입니다.

용어 한 줄: E2E 테스트(End-to-End, 끝에서 끝까지) 란 "사용자가 실제로 하는 행동을 처음부터 끝까지 따라가며 확인하는 테스트"입니다. 일상 비유로는 부품 검사 말고 실제 도로에서 차를 직접 몰아보는 것과 같습니다.

일상 비유로 먼저

자동차 검사를 떠올려 보세요. 엔진·브레이크·타이어를 따로 보는 게 유닛 테스트입니다. 그것들을 합쳐서 잘 연결됐는지 보는 게 통합 테스트입니다. 실제로 도로에서 시동 걸고 출발해 주차까지 해보는 게 E2E 테스트입니다.

용어 한 줄: 통합 테스트(integration test) 란 "여러 부품이 합쳐졌을 때 잘 연결되는지 보는 테스트"입니다. 일상 비유로는 조립한 가구가 흔들리지 않는지 흔들어보는 것과 같습니다.

유닛 테스트 vs E2E 테스트 한눈에

용어 한 줄: Playwright(플레이라이트) 는 "진짜 브라우저를 열어서 사람 대신 클릭하고 확인해 주는 E2E 테스트 도구"입니다. 마이크로소프트가 관리합니다. 일상 비유로는 정해진 동선대로 매장을 돌아보는 로봇 점원과 같습니다.

E2E 테스트는 왜 사용자가 주도할까

유닛 테스트는 "최소한 부품은 멀쩡하다"는 기본 보장입니다. E2E 테스트는 "사용자가 실제로 이렇게 쓸 거다"라는 시나리오를 사람이 정해줘야 합니다. 그래서 어떤 화면을 어떤 순서로 확인할지, 사용자가 직접 정하고 클로드 코드에 알려줍니다.

Playwright 테스트 폴더 구조 예시

tests/
├── auth/              # 로그인·회원가입·로그아웃 테스트
├── cities/            # 도시 필터·선호도·이동 테스트
├── core/              # 홈페이지·내비게이션·반응형 테스트
├── fixtures/          # 테스트용 미리 만든 데이터
├── page-objects/      # 페이지별 요소를 클래스로 묶은 것
└── utils/             # 테스트 도우미 함수
playwright.config.ts   # Playwright 설정 파일

용어 한 줄: Page Object Model(페이지 오브젝트 모델) 이란 "페이지마다 버튼·입력칸 같은 요소를 한 군데(클래스)에 모아두는 정리 방식"입니다. 일상 비유로는 자주 쓰는 연락처를 사람별로 묶어둔 주소록과 같습니다. 화면이 바뀌어도 이 한 군데만 고치면 됩니다.

용어 한 줄: fixture(픽스처) 란 "테스트할 때 미리 준비해 두는 고정 데이터"입니다. 일상 비유로는 요리 실습 전에 미리 손질해 둔 재료와 같습니다.

잘못된 예 vs 올바른 예

잘못된 생각: "유닛 테스트만 통과하면 다 끝난 거 아냐?" → 부품은 멀쩡해도 합치면 깨질 수 있습니다.

올바른 생각: "핵심 사용자 흐름은 E2E로도 한 번 확인하자." → 로그인 → 필터 선택 → 결과 확인 같은 전체 흐름을 검증합니다.

이럴 때 이렇게: 가장 중요한 사용자 흐름(예: 로그인하고 핵심 기능 쓰기) 하나부터 E2E로 만들어 보세요.

여기서 한 번 점검

• 유닛 → 통합 → E2E의 계층을 이해했나요?
• E2E를 사용자가 주도해야 하는 이유를 설명할 수 있나요?
• Page Object Model의 목적을 이해했나요?
• fixtures와 page-objects 폴더의 역할 차이를 아나요?

5. Playwright MCP로 E2E 테스트 자동 만들기

이런 적 있죠? E2E 테스트를 짜려니 page.goto(), page.getByRole(), expect().toBeVisible() 같은 명령을 일일이 손으로 적어야 한다. 외울 것도 많고 번거롭다.

그게 바로 "API를 직접 다 쓰기"의 번거로움입니다. 이걸 줄여주는 게 Playwright MCP입니다. 이걸 붙이면 "이거 테스트해줘"라고 평소 말로 시켜도, 클로드 코드가 알아서 Playwright 명령으로 바꿔 테스트를 만들고 실행까지 합니다.

용어 한 줄: MCP(Model Context Protocol) 란 "클로드 코드에 외부 도구를 끼워 쓰게 해주는 연결 규격"입니다. 일상 비유로는 다양한 기기를 꽂아 쓰는 USB 포트와 같습니다. (MCP의 기본 개념은 앞 장에서 다뤘습니다.)

일상 비유로 먼저

레스토랑에서 음식 주문을 떠올려 보세요. 직접 요리하면 재료 손질부터 다 해야 합니다(=Playwright 명령을 손으로 다 적기). 주문만 하면 주방이 알아서 만들어 줍니다(=말로 시키면 MCP가 알아서 테스트 작성).

용어 한 줄: 커스텀 커맨드(custom command) 란 "자주 쓰는 지시를 .claude/commands/ 폴더에 파일로 저장해 두고, /이름으로 꺼내 쓰는 나만의 명령"입니다. 일상 비유로는 자주 시키는 메뉴를 저장해 둔 단골집 주문서와 같습니다.

단계 01 — Playwright 구조 구상하고 세팅하기

먼저 폴더 구조를 구상시키고, 그다음 세팅을 시킵니다. 여기서도 "아직 테스트는 작성하지 마"를 빠뜨리지 마세요.

1) E2E 테스트를 Playwright로 구현할 건데
   폴더 구조를 어떻게 하면 좋을지 구상해줘. 아직 테스트를 작성하지는 말아줘.

2) 계획대로 Playwright 세팅을 해주고 테스트 폴더 구조를 만들어줘.
   아직 테스트는 작성하지 말아줘.

이 과정에서 보통 이런 일이 끝납니다. @playwright/test 패키지 설치 playwright.config.ts 설정 파일 생성 tests/ 폴더 구조 생성 package.json에 E2E 테스트 스크립트 추가

단계 02 — CLAUDE.md에 테스트 구조 적어두기

CLAUDE.md 파일에 E2E 테스트 구조에 대한 설명을 작성해줘.

이렇게 적어두면, 이후 클로드 코드가 테스트를 만들 때마다 이 설명을 참고합니다. 매번 구조를 다시 설명하지 않아도 됩니다.

용어 한 줄: CLAUDE.md 란 "이 프로젝트에서 클로드 코드가 늘 참고하는 안내문 파일"입니다. 일상 비유로는 새 직원에게 건네는 업무 매뉴얼과 같습니다.

단계 03 — Playwright MCP 등록하기

터미널에서 이 명령 한 줄로 등록합니다.

claude mcp add playwright -s project npx @playwright/mcp@latest

등록하면 .mcp.json 파일에 이렇게 기록됩니다.

{
  "mcpServers": {
    "playwright": {
      "type": "stdio",
      "command": "npx",
      "args": ["@playwright/mcp@latest"],
      "env": {}
    }
  }
}

단계 04 — 커스텀 커맨드 만들기

.claude/commands/create-e2e-test.md 파일을 만들어, 자주 쓸 지시를 저장합니다.

# E2E 테스트 생성기
너는 지금부터 Playwright로 E2E 테스트를 생성하는 QA 전문가야.
- $ARGUMENT로 입력한 테스트 요소들을 잘 이해해줘.
- Playwright MCP를 사용해서 테스트를 진행해줘.
- 테스트가 전부 끝나면 E2E 테스트를 작성해줘.
- 실패하는 테스트가 있다면 성공할 때까지 개선해줘.

용어 한 줄: $ARGUMENT 란 "커스텀 커맨드를 실행할 때 내가 뒤에 붙여 넣는 내용이 들어갈 자리"입니다. 일상 비유로는 빈칸 채우기 문제의 빈칸과 같습니다.

단계 05 — 커맨드 실행하기

이제 /create-e2e-test 뒤에 평소 말로 무엇을 확인할지 적으면 됩니다.

/create-e2e-test
- http://localhost:3000 으로 이동해줘
- 홈페이지에 로고가 존재하는 걸 확인해줘
- 홈페이지에 도시 카드들이 존재하는 걸 확인해줘
- 처음 접속하면 필터가 적용 안 돼 있는 걸 확인해줘

그러면 클로드 코드가 이 말을 Playwright 명령으로 바꿔 테스트 코드를 만들고, 실제 브라우저에서 돌려봅니다.

만들어지는 테스트 코드는 이런 모습

test.describe('홈페이지 기본 기능 테스트', () => {
  test.beforeEach(async ({ page }) => {
    await page.goto('http://localhost:3000');  // 각 테스트 전에 홈으로 이동
  });

  test('로고가 보이는지 확인', async ({ page }) => {
    const logo = page.getByRole('link', { name: 'K-NOMAD HUB' });
    await expect(logo).toBeVisible();
  });
});

테스트 실행하고 결과 보기

npx playwright test          # 모든 테스트 실행 (여러 브라우저)
npx playwright show-report   # 마지막 결과 리포트 열기

Playwright는 진짜 브라우저(Chromium, Firefox 등)를 띄워 테스트합니다. 그래서 실패하면 그 순간의 스크린샷과 동영상까지 남겨줍니다. "어디서 왜 틀렸는지"를 눈으로 바로 확인할 수 있어서 유닛 테스트보다 직관적입니다.

잘못된 예 vs 올바른 예

잘못된 방식: MCP도 안 붙이고 Playwright 명령을 처음부터 손으로 다 적는다. → 외울 것도 많고 오타도 잦습니다.

올바른 방식: Playwright MCP를 등록하고, 커스텀 커맨드로 평소 말로 시킨다. → 클로드 코드가 명령 변환과 실행을 알아서 합니다.

이럴 때 이렇게: 같은 종류의 E2E 테스트를 자주 만들 거라면, 지시를 커스텀 커맨드 파일로 저장해 두고 /이름으로 재사용하세요.

한 걸음 더 ▸ 명령·옵션은 바뀔 수 있어요

claude mcp add, @playwright/mcp@latest, npx playwright test 같은 명령과 옵션은 원서/노트 기준 예시입니다. 도구가 자주 업데이트되므로, 최신 명령·옵션은 각 도구 공식 문서(Playwright, Playwright MCP 저장소)에서 확인하세요. 또 Playwright MCP는 서드파티(외부 제작) 도구이므로, 설치·옵션은 원서 작성 시점 기준 소개이며 자세한 내용은 해당 도구 공식 저장소를 확인하는 게 안전합니다.

여기서 한 번 점검

• Playwright MCP를 등록하는 명령(claude mcp add)을 아나요?
• 커스텀 커맨드로 E2E 생성을 자동화하는 방법을 이해했나요?
• npx playwright test와 npx playwright show-report의 차이를 아나요?
• 실패 시 스크린샷·동영상을 주는 장점을 설명할 수 있나요?

연습문제

문제 1 (기본) 유닛 테스트, 통합 테스트, E2E 테스트의 차이를 한 가지씩 예를 들어 설명해 보세요.

도움말: 유닛 = 함수 하나(예: 좋아요 토글 함수)를 따로 확인. 통합 = 여러 부품 연결(예: DB와 localStorage 폴백이 함께 도는지) 확인. E2E = 사용자 전체 흐름(예: 홈 접속 → 필터 선택 → 결과 확인)을 브라우저에서 확인.

문제 2 (기본) 클로드 코드에게 테스트를 시킬 때 "아직 작성하지 말아줘"를 붙이는 이유는 무엇일까요?

도움말: 이 말이 없으면 구조를 검토하기도 전에 코드를 쏟아냅니다. 구조 → 목록 → 코드 순서로 검토하기 위해 붙입니다.

문제 3 (중급) 서브에이전트를 병렬로 굴릴 때 인프라·모킹 담당(Agent 4)을 먼저 끝내야 하는 이유를 설명해 보세요.

도움말: 다른 테스트들이 모킹과 설정 파일에 기대고 있어서, 그게 없으면 테스트가 아예 실행되지 않기 때문입니다.

정리 한눈에 보기

테스트 시키는 4단계 흐름: 구조 구상 → 목록 정리 → (서브에이전트) 병렬 계획 → 코드 작성. 모두 앞에 "아직 작성하지 마"를 붙여 단계마다 검토합니다.

다음 장 예고: 다음 장에서는 또 다른 활용법을 다룹니다. 지금 몰라도 됩니다.